System and method for pushing data to a mobile device

ABSTRACT

A system for handling information requests from mobile devices ( 100 ) includes a memory ( 1100 ), a state prediction module ( 1200 ), and a push module ( 1300 ). The memory ( 1100 ) is operable to store data requests received from the mobile devices ( 100 ). The state prediction module ( 1200 ) is operable to access the memory ( 1100 ) to predict forecasted data requests for a mobile device ( 100 ) based on the stored data requests. The push module ( 1300 ) is operable to receive the forecasted data requests from the state prediction module ( 1200 ) and in response request and receive response data related to the forecasted data requests and prepare the response data for transmission to the mobile device ( 100 ) over a wireless network ( 105 ).

This application claims the benefit of and priority to U.S. ProvisionalApplication Ser. No. 60/362,930, which was filed Mar. 11, 2002. Theentire disclosure of Provisional Application Ser. No. 60/362,930,including the specification, drawings, and attachments, is incorporatedinto this present application by reference.

BACKGROUND

1. Technical Field

This application relates generally to systems and methods for providingdata to a mobile communication device (“mobile device”), and inparticular to systems and methods for pushing forecasted data to amobile device.

2. Description of the Related Art

Typically, when a user of a desktop computer or a mobile device requestsdata, the user will often make another, subsequent data request afterexamining the reply data received in response to the initial datarequest. Desktop computers typically have high-bandwidth, low-latencyaccess to computer networks, such as local area networks (LANs), widearea networks (WANs), and the Internet. Thus, response data to thesesubsequent data requests are usually provided quickly when using adesktop computer.

A mobile device that communicates over a wireless network, however,typically does not have a relatively high-bandwidth, low-latencycommunication path to these networks, because many wireless networks mayhave signal propagation delays, a limited RF spectrum, and signalfade-outs. Accordingly, when the user of the mobile device requestssubsequent data, the user typically must contend with the inherentlatency and bandwidth limitations of the wireless network. A number ofwireless communication protocols have been developed to accommodatemobile device data requests, including Wireless Application Protocol(WAP), compressed Hypertext Markup Language (cHTML), Extensible HTML(xHTML), and Extensible Markup Language (XML), and others. Nevertheless,these communication protocols are still subject to the inherent latencyand bandwidth characteristics of the wireless network. Thus, the user ofthe mobile device must often wait for reply data to be received at themobile device in response to the subsequent data request.

SUMMARY

A system for handling information requests from mobile devices includesa memory, a state prediction module, and a push module. The memory isoperable store data requests received from the mobile devices. The stateprediction module is operable to receive a data request from a mobiledevice and in response access the memory and predict a forecasted datarequest based on the received data request and the stored data requests.The push module is operable to receive the received data request and theforecasted data request from the state prediction module and in responserequest and receive response data related to the received data requestand the forecasted data request and prepare the response data fortransmission to the mobile device over a wireless network.

A system for handling data requests from mobile devices comprises amemory, a state prediction module, and a push module. The memory isoperable to store data requests received from at least one mobiledevice. The state prediction module is operable to access the memory andpredict a first forecasted data request for a mobile device based on thestored data requests. The push module is operable to receive the firstforecasted data request from the state prediction module and in responserequest and receive first response data related to the first forecasteddata request and prepare the first response data for transmission to themobile device over a wireless network.

A system for handling information requests from mobile devices includesa data collection unit, a data adjustment unit, an analysis unit, and apush unit. The data collection unit is operable to receive and storedata requests received from the mobile devices and to store predictiondata based on the stored data requests. The data adjustment unit isoperable to receive a data request from a mobile device and access thestored data requests and generate the prediction data and store theprediction data in the data collection unit. The analysis unit isoperable to access the prediction data stored in the data collectionunit and execute a prediction algorithm to predict forecasted datarequests. The push unit is operable to receive the received data requestand the forecasted data requests and in response request and receiveresponse data related to the received data request and the forecasteddata requests and prepare the response data for transmission to themobile device over a wireless network.

A mobile communication device includes a communication subsystemoperable to communicate over a wireless network, a memory subsystemoperable to store data, and a processing subsystem operable to instructthe communication subsystem to transmit and receive data over thewireless network and to store data to and read data from the memorysubsystem. A client program comprising processing subsystem executableinstructions is stored in the memory subsystem, and is operable topredict data requests and receive response data to the data requests. Aclient program cache is operable to store the response data, and a pushcache is operable to store forecasted data based on data requests.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustrative communication system in which the systems andmethods described herein may be used;

FIG. 2 is an embodiment of a system for handling mobile deviceinformation requests;

FIG. 3 is another embodiment of a system for handling mobile deviceinformation requests;

FIG. 4 is a flow diagram of a method of handling mobile deviceinformation requests;

FIG. 5 is a flow diagram illustrating a mode selection in a predictionmodule;

FIG. 6 is a flow diagram illustrating another method of handling mobiledevice information requests;

FIG. 7 is a diagram of another embodiment of a system for handlingmobile device information requests;

FIG. 8 is a weighted graph model of mobile device activity;

FIG. 9 shows a transition matrix T structure and adjustment processduring a training phase;

FIG. 10 is a flow diagram illustrating a candidate state selectionprocess; and

FIG. 11 is a schematic diagram of an exemplary mobile device.

DETAILED DESCRIPTION

FIG. 1 is an illustrative communication system in which the systems andmethods described herein may be used. The system includes a data portal10, the Internet 20, a data server 40, a wireless gateway 85, wirelessinfrastructure 90, a wireless network 105, and a mobile device 100.Other systems may also be used with the system and method disclosedherein.

The data portal 10 and the data server 40 are illustratively WAPcompliant devices. Other data portals or servers, such as an HTML,cHTML, xHTML, and XML servers and portals can also be used. Typically,the portal 10 and server 40 may be similar devices, i.e., the portal 10may be realized by a server, and may also function as a proxy server.The portal 10, however, is typically administered by a mobile devicecarrier or service provider.

The wireless gateway 85 and the wireless infrastructure 90 provide alink between the Internet 20 and wireless network 105, collectivelyforming an exemplary information transfer mechanism. The wirelessinfrastructure determines the most likely network for locating a givenuser and may track the user as they roam between countries or networks.

The wireless infrastructure 90 includes a series of connections to thewireless network 105. These connections may be Integrated ServicesDigital Network (ISDN), Frame Relay or T1 connections using the TCP/IPprotocol used throughout the Internet.

As used herein, the term “wireless network” may cover many differenttypes of wireless networks, such as (1) data-centric wireless networks,(2) voice-centric wireless networks and (3) dual-mode networks that cansupport both voice and data communications over the same physical basestations. In addition to these types of wireless networks, otherwireless networks may also be used.

Examples of combined dual-mode networks include, but are not limited to(1) the Code Division Multiple Access (CDMA) network that has beendeveloped and is operated by Qualcomm, (2) the Groupe Special Mobile orthe Global System for Mobile Communications (GSM) and the General PacketRadio Service (GPRS) network both developed by the standards committeeof CEPT, and (3) the future third-generation (3G) networks like EnhancedData-rates for Global Evolution (EDGE) and Universal MobileTelecommunications Systems (UMTS). GPRS is a data overlay on the verypopular GSM wireless network, operating in virtually every country inEurope.

Examples of data-centric networks include the Mobitex™ Radio Network,which has been developed by Eritel and Ericsson of Sweden, and isoperated by BellSouth (Cingular) Wireless Data in the United States andRogers/Cantel in Canada, and the DataTAC™ Radio Network, which has beendeveloped by Motorola and is operated by American Mobile SatelliteCorporation (AMSC), now called Motient, in the United States and BellMobility in Canada. Examples of voice-centric data networks includePersonal Communication Systems (PCS) networks like CDMA, GSM, and TDMAsystems that have been available in North America and worldwide fornearly 10 years.

The portal 10 may also be located within a company LAN or WAN, or inanother network, such as in a large Application Service Provider (ASP),and provides an interface for information exchange over the Internet 20.The portal 10 may also include dynamic database storage engines thathave predefined database formats for data such as calendars, to-dolists, task lists, e-mail and documentation, and may also provide linksto information sources that it serves, such as the WAP deck 17, as wellas links to information served by other servers, such as WAP deck 37served by the WAP server 40, and other systems connected to the Internet20.

The WAP decks 17 and 35 comprise documents written in the WirelessMarkup Language (WML) protocol. WML uses the metaphor of card decks fordocuments, and each page of a WML document is referred to as a card, andthe entire document is referred to as a deck. Thus, a WAP documenttypically comprises a series of sections or pages, called cards, each ofwhich holds the data for one screen/window in a WAP browser.

The WAP deck 17 may be requested by a mobile device user, and isdelivered to the mobile device 100 via wireless transmission, typicallyover a radio frequency (RF) link from a base station in the wirelessnetwork 105. The particular network 105 may be realized by any wirelessnetwork over which information may be exchanged with the mobile device100.

When a user requests data at the mobile device 100, the mobile device100 conducts a data pull of the requested information. The mobile device100 typically sends a Uniform Resource Identifier (URI), such as URI 15that corresponds to a resource request from the portal 10. The mobiledevice 100 may be configured to send other types of data requestsaccording to different communication protocols in addition to theexemplary URI 15, such as a URL for a web page, an EP address of aserver, a file transfer protocol (FTP) request, and the like.Additionally, while the URI 15 illustratively corresponds to the portal10, the URI 15 may instead correspond to other devices or systems incommunication with the Internet 20.

When the portal 10 receives the URI 15, the portal 10 normally respondsby sending the WAP deck 17 to the mobile device 100. The WAP deck 17 istypically transmitted to the mobile device 100 via the wireless gateway85. If the portal 10 has the WAP deck 17 stored locally, then it mayimmediately send the WAP deck 17 to the mobile device 100. If the portal10 does not have the WAP deck 17 stored locally, then it may request andreceive the WAP deck 17 from another source. Upon receiving the WAP deck17, the mobile device 100 presents the WAP deck 17 to the user, and thedata pull is completed.

Typically, upon receiving the WAP deck 17, the user of the mobile device100 may thereafter request another WAP deck after examining theinformation presented in the WAP deck 17. For example, if the WAP deck17 includes stock quote information for a number of stocks, the user ofthe mobile device 100 may subsequently request information related toone of the number of stocks, either from the same portal 10, or fromanother portal or server in communication with the Internet 20. The usermust then wait until the corresponding information or data is receivedat the mobile device 100.

Additionally, if the information received at the mobile device 100comprises additional embedded URIs, then selection of the URI by theuser will cause the mobile device 100 to issue another URI request, andthe user must then wait until the corresponding information or data isreceived at the mobile device 100.

To minimize the associated latency for these subsequent requests, thesystems and methods disclosed herein push forecasted responseinformation in addition to the response information transmitted to themobile device 100. A forecasted data request based on previous datarequests issued from the mobile device 100 or other mobile devices isgenerated by the portal 10. If the portal 10 has the response data tothe forecasted data request stored locally, then it may immediately sendthe response data with the WAP deck 17 to the mobile device 100. If theportal 10 does not have the response data stored locally, then it mayrequest and receive the response data from another source. Oncereceived, the response data is provided to the mobile device 100 withthe WAP deck 17.

The forecasted data request may also be provided to the mobile device100. For example, when the WAP deck 17 is transmitted to the mobiledevice, predicted information 18 is pushed with the WAP deck 17. If theforecasted data request is a URI 35, then the predicted information 18may include the forecasted URI 35 and the corresponding WAP deck 37. Thepredicted information 18 may be stored in a cache within the mobiledevice 100, or a similar memory store within the mobile device 100.

The URI 35 may, for example, be related to a link found in the WAP deck17. If the URI 35 is requested by the mobile device 100, and the URI 35and corresponding deck 37 was not stored in the cache of the mobiledevice 100, then the mobile device 100 would transmit the URI 35 queryto the portal 10. However, since the URI 35 and corresponding WAP deck37 were provided in the predicted information 18, the mobile device 100need not actually transmit the URI request, as the corresponding deck 37is available id the mobile device 100 cache. Thus, a subsequent requestto the deck 17 is preempted, thereby reducing latency experienced by theuser of the mobile device 100.

FIG. 2 is an embodiment of a system 1000 for handling mobile device 100information requests. The mobile device 100 typically comprises a clientprogram 110 and an associated cache memory 120. An exemplary mobiledevice 100 may be of the type described with reference to FIG. 11,below. While only one mobile device 100 is illustrated, a plurality ofmobile devices may also be in communication with the system 1000.

The system 1000 includes a storage module 1100, a prediction module1200, and a push module 1300. The storage module 1100, prediction module1200 and push module 1300 may collectively form a push server responsiveto data requests from the mobile device 100. The push server may beembodied in a single computer, or may instead be distributed over aplurality of computer devices. For example, the storage module 1100 andthe prediction module 1200 may be located on a first computer device,and the push module 1300 may be located on a second computer device incommunication with the first computer device.

Each of the storage module 1100, prediction module 1200, and push module1300 may comprise a software program or software system structure andassociated hardware for performing the programmed tasks. Any number ofsoftware languages or software programming platforms may be used toconstruct these modules. Additionally, although the storage module 1100,prediction module 1200, and the push module 1300 are depicted asseparate modules, the modules may be combined into a single module toconsolidate functional tasks, or, alternatively, may be subdivided todistribute functional tasks.

In the illustrative embodiment of FIG. 2, each data request of themobile device 100 is modeled as a state. The storage module 1100 isoperable to receive and store states transmitted from the mobile device100 and other mobile devices. In one embodiment, a mobile device statemay comprise a URI.

The prediction module 1200 is operable to receive states from the mobiledevice 100 and in response access the storage module 1100, and predictone or more forecasted states based on the received data request and thestored states. The prediction module 1200 may execute a predictionalgorithm, such as a Markov chain, an n-gram sequence model, a weightedmost recently used algorithm, or other prediction algorithm. Theprediction may involve comparing the received state to the storedstates, or comparing the received state to prediction data generatedfrom the stored states. In the case of comparing the received state tothe prediction data generated from the stored states, the stored statesmay be deleted after the prediction data are generated to conservestorage space.

The prediction module 1200 provides the forecasted states to the pushmodule 1300. The push module 1300 is operable to receive the requestedstate from the mobile device 100 and the predicted states from theprediction module 1200, and in response request and receive responsedata responsive to the forecasted state and the requested states. Forexample, if the mobile device state and forecasted states comprise URIs,then the push module 1300 executes URI queries. The response data isthen transmitted to the mobile device 100. In one embodiment, theresponse data also includes the forecasted states.

In another embodiment, the prediction module 1200 predicts forecastedstates and provides the forecasted states to the push module 1300independent of receiving a state from the mobile device 100. The pushmodule 1300 is operable to receive the forecasted states from theprediction module 1200 and request and receive response data responsiveto the forecasted states. The prediction module 1200 may be furtherconfigured to predict forecasted states and provide the forecastedstates to the push module on a periodic basis. For example, if a user ofthe mobile device 100 typically access a news service and a sportsservice during a certain time of day, e.g., between the hours of 7:00 AMand 8:00 AM, the prediction module 1200 may predict the requisite URIqueries for the news service and the sports service within this timeperiod, and provide the URI queries to the push module 1300. The pushmodule 1300 then executes the URI queries, and the response data istransmitted to the mobile device 100. This operation may occurindependent of receiving a state from the mobile device 100, e.g., themobile device 100 may be in a standby mode, or the user may not have yetselected a particular state relating to the news service or sportsservice.

Accordingly, the user of the mobile device 100 will have the informationrelated to the news service and sports service information available atthe mobile device 100 when the user does select the news service orsports service. To help maintain accuracy of future predictions, themobile device 100 may be further configured to transmit a successfulprediction notification back to the prediction module 1200 when themobile device 100 accesses the predicted states. Thus, the predictionmodule 1200 may then update prediction algorithm data to reflect whethera successful prediction notification was received from the mobile device100. For example, the failure to receive successful notifications for aparticular predicted state during a time period may result in theprediction module 1200 removing the particular state from the predictiondata, or lowering the likelihood of predicting the particular state inthe future.

The successful prediction notification may also comprise data indicatingwhether the mobile device 100 accessed the response data provided. Themobile device 100 can be configured to determine whether the responsedata pushed from the push module 1300 has been accessed during an accesstime period. Thus, instead of waiting to receive the successfulprediction notification during the time period, the prediction module1200 may interrogate the successful prediction notification when it isreceived. Accordingly, if the response data has been accessed during theaccess time period, then the successful prediction notificationindicates that a successful prediction occurred. If the response datahas not been accessed during the access time period, however, then thesuccessful prediction notification indicates that an unsuccessfulprediction occurred.

In another embodiment, the push module 1300 may be implemented by arequest module operable to receive the received data request and theforecasted data request from the prediction module and in response issuerequests for response data related to the received data request and theforecasted data request to be transmitted to the mobile device 100 overa wireless network. Thus, the request module need not receive therespective response data for the received data request and theforecasted data request; rather, response data for the received datarequest and the forecasted data request are provided to the mobiledevice 100 via communications from devices responsive to the respectiverequests. In a variation of this embodiment, the request module mayseparately transmit the forecasted states to the mobile device 100.

FIG. 3 provides another embodiment of the system 1000 for mobile device100 information requests. In this embodiment, the storage module 1100includes memory stores 1102 and 1104 for storing mobile device statesand prediction data. Typically, the transmission from the mobile device100 will also include a mobile device 100 identifier, and thus a statehistory for each mobile device 100 may be stored in the memory store1102. Likewise, prediction data corresponding to each mobile device incommunication with the system 1000 may also be stored in the memorystore 1104.

The prediction module 1200 is operable to predict one or more forecastedstates based on the received data request and the stored states.Illustratively, the prediction module 1200 may predict the forecastedstates by utilizing only the previous states stored in the memory store1102, or may also be configured to utilize the prediction data stored inmemory store 1104. Alternatively, the prediction module 1200 may beconfigured to rely solely on the prediction data stored in the memorystore 104 to predict the forecasted states.

The prediction module 1200 may operate in a training mode 1202 togenerate prediction data to be stored in the memory store 1104, and thentransition to an operational mode 1204. In this embodiment, theprediction module 1200 defines one or more collection frames duringwhich time states are collected for the mobile device 100 or othermobile devices. At the expiration of the collection frame, predictiondata are generated or adjusted. The prediction data are then evaluatedto determine whether to define another collection frame for furtheradjustment of the prediction data, or to transition to an operationalmode 1204.

During the operational mode, the prediction module may operate in anatomic mode 1212, a group mode 1214, or a mixed mode 1216. In the atomicmode 1212, the prediction module 1200 uses historical states of themobile device 100, or historical states from a group of relativelyhomogenous users, to predict forecasted states.

An example of a group of homogenous users is employees of a particulardivision in a company. Another example of a group of homogenous users isusers with similar data request histories. Other techniques of defininggroups of homogenous users may also be used.

In the group mode 1214, the prediction module 1200 uses historicalstates on a larger group of mobile devices 100. For example, a groupmode prediction could be based on the historical states of all users ofmobile devices 100.

Finally, in mixed mode 1216, the prediction module 1200 operates firstin the atomic mode 1212, and then switches to the group mode 1214 if astrong prediction cannot be made in the atomic mode 1212. The strengthof the prediction may be measured by the ability to recognize areference pattern, or the likelihood of the prediction being correctexceeding a threshold probability, or by other methods.

In operation, the mobile device 100 may issue a data request via the URI15. The URI 15 is transmitted over the wireless network 105 and theInternet 20 to the storage module 1100, and the state is stored in thememory store 1102. The URI 15 is then provided to the prediction module1200, which accesses the memory stores 1102 and/or 1104 and predicts oneor more forecasted states. In this example, the prediction module 1200predicts only one state, URI 35, as the forecasted state.

The URIs 15 and 35 are provided to the push module 1300, which thenexecutes the respective URI queries. The URI 15 may correspond to serverlocated on a corporate LAN 21, in which case the WAP deck 17 is providedin response. The URI 35 may correspond to a server 22 located somewherein the Internet 20, and the corresponding WAP deck 37 is provided inresponse.

The WAP deck 17, URI 35, and the WAP deck 37 are then transmitted to themobile device 100 as response data. Upon receiving the response data,the WAP deck 17 is accessed by the client program 110 operating on themobile device 100, and the URI 35 and WAP deck 37 are stored in theclient program cache 120. If the user thereafter requests the URI 35,the prediction is successful. As a result of the successful prediction,the WAP deck 37 is provided from the cache 120, and is thus immediatelyavailable to the user of the mobile device 100.

In another embodiment, the cache 120 of the mobile device 100 may alsocomprise a client program cache 122 and a push cache 124. The clientprogram 110 may be configured to store the response data to therequested state, such as the WAP deck 17 provided in response to the URI15; in the client program cache 122, and store the response data to theforecasted state, such as the URI 35 and WAP deck 37, in the push cache124. Typically, data stored in the cache 120 may have associated refreshor expiry data, such as an expiration header field, that instructs theclient program 110 to query a data source and request updated data. Inthis embodiment, such expiry data or refresh data in the response datastored in the push cache 124 is ignored by the client program 110. Thus,the client program 110 may search the push cache 124 for forecasted dataresponsive to a second, subsequent state, and will not execute a datarequest if the expiry data or refresh data indicates stale data.

If the response data stored in the push cache 124 is responsive to thesubsequent state, i.e., the next state was correctly predicted by theprediction module 1200, then the client program 110 may transfer theforecasted response data from the push cache 124 to the client programcache 122. If the response data stored in the push cache 124 is notresponsive to the subsequent state, however, then the forecastedresponse data may be deleted, and the state requested by the mobiledevice 100 is transmitted over the wireless network 105 to the storagemodule 1100.

One or more forecasted states may be predicted and pushed to the mobiledevice 100. For example, if four states are predicted, and the responsedata for the four states are provided to the mobile device 100, then themobile device 100 need not transmit a data request over the wirelessnetwork as long as the subsequent states requested by the user are amongthe four predicted states. In yet another embodiment, upon exhaustingthe successful predictions, the mobile device 100 transmits a successfulprediction notification to the prediction module 100. The predictionmodule 1200 then predicts additional forecasted states based on the lastsuccessfully predicted state of the mobile device 100, and pushes theresponse data to the mobile device 100. Thus, a new set of response datafor one or more predicted states may be pushed to the mobile device 100without user intervention.

In addition to being operable to predict one or more forecasted statesbased on the received data request and the stored states, the predictionmodule 1200 may also be operable to predict one or more forecastedstates independent of receiving a state from the mobile device 100.Furthermore, the mobile device 100 may be further operable to transmitback to the prediction module 1200 a successful prediction notificationas confirmation that the prediction module 1200 correctly predicted theone or more forecasted states independent of a received data request.The operation of the prediction module 1200, push module 1300, and themobile device 100 in this configuration are as described with referenceto FIG. 2 above.

In another embodiment, upon predicting the forecasted states, theprediction module 1200 may further compare a resource metric associatedwith pushing data related to the forecasted states to a system metric1220. The system metric 1220 may be a cost metric, such as a cost ofproviding the data to the mobile device 100, or a resource metric, suchas available system bandwidth. Other metrics may also be used. Thesystem metric 1220 may be used to update or adjust the prediction datastored in the memory store 1104, as indicated by arrow 1222.

Based on the system metric 1220, the prediction module 1200 maydetermine the maximum number of particular states and related data topush to the mobile device 100 that is cost effective. If the particularforecasted states are not cost effective, or exceed the maximum numberof cost effective states, then some, or even all, of the forecastedstates may be cancelled. Alternatively, the prediction module may befurther configured to generate another set of forecasted states, ormodify the first set of forecasted states if the first set of predictedstates is not cost effective.

FIG. 4 is a flow diagram 500 of a method of handling a mobile deviceinformation request. At step 502, a new state for the mobile device isrecorded by the storage module 1100. Typically, the new statecorresponds to a data request received from the mobile device via atransmission over a wireless network. The new state may correspond to aparticular mobile device if a mobile device identifier is included inthe data request.

At step 504, the prediction data may be adjusted by the predictionmodule 1200. Depending on the prediction algorithm implemented in theprediction module 1200, the prediction data may be updated with each newstate recorded, or may alternatively be updated only if the new staterenders the existing prediction data inaccurate or in need ofadjustment. Factors that may determine whether the prediction data isupdated may include sample space size, history size, the particularprediction algorithm, and the like.

At step 506, the prediction module conducts a state analysis to predictforecasted states of the mobile device 100. The prediction may besubject to a mode selection, such as an atomic mode 1212, a group mode1214, or a mixed mode 1216.

At step 508, the forecasted states are provided to the push module 1300,which requests the new state data requested by the mobile device and theforecasted state data related to the forecasted states. Finally, at step510, response data including the new state data and the forecasted statedata are prepared for transmission to the mobile device. The responsedata may comprise only the new state data and the forecasted state data,or may further include the forecasted state corresponding to theforecasted state data.

In another embodiment, the push module 1300 may be operable to determinewhether the response data includes further state requests, as shown instep 512. For example, an HTML document may comprise URLs to other dataservers, and accessing the HTML document will cause a browser program toissue a query to the other data servers associated with the embeddedURLs.

To obviate the need for such operations at the mobile device 100, thepush module, upon determining that the response data includes furtherstate requests, requests further response-data in response to thefurther state requests, as shown in step 514. Upon receiving the furtherresponse data, the push module 1300 prepares response data that includesthe new state data and the forecasted state data, and also includes thefurther response data related to the further state requests, as shown instep 516.

FIG. 5 is a flow diagram 600 illustrating a mode selection in theprediction module 1200. At step 602, the prediction module 1200 selectsthe atomic mode 1212 as a default mode. Accordingly, the predictionmodule 1200 utilizes the historical states of a particular mobile device100, or historical states from a group of relatively homogenous users topredict forecasted states.

At step 604, the prediction module 1200 predicts forecasted states basedon the atomic mode data. At step 606, the prediction module 1200determines whether the forecasted states are valid. The validity of theforecasted states may be determined by a corresponding probability ofthe prediction exceeding a threshold, or by the prediction module 1200being able to determine forecasted states based on the atomic data, orby other methods.

If the prediction is not valid, then the prediction module 1200 selectsthe group mode 1214, as shown in step 608. At step 610, the predictionmodule 1200 predicts forecasted states based on the group mode data. Atstep 612, the prediction module 1200 determines whether the forecastedstates are valid.

If the forecasted states predicted in step 604 were valid, or,alternatively, if the forecasted states predicted in step 604 wereinvalid and the forecasted states predicted in step 610 are valid, thenin step 614 the new state data and the forecasted state data arerequested. In step 616, the response data received are prepared fortransmission to the mobile device. Thus, the forecasted states andcorresponding state data are pushed to the mobile device along with thestate data requested by the mobile device.

If the forecasted states predicted in step 610 were invalid, however,then the new state data is requested in step 618, and the response datarelated to the new state data received in step 620 is prepared fortransmission to the mobile device. Thus, only the state data requestedby the mobile device is provided to the mobile device.

FIG. 6 is a flow diagram 630 illustrating another method handling mobiledevice information requests. In the flow diagram 630, the predictionmodule 1200 predicts forecasted states independent of receiving a statefrom the mobile device 100. The method of the flow diagram 630 may beimplemented after set of prediction data for a particular mobile device100 or group of mobile devices has been developed, such as describedwith reference to steps 502 and 504 of FIG. 4.

At step 632, the prediction module 1200 predicts forecasted states. Theprediction may be triggered by an event independent of receiving a staterequest from a mobile device 100. The event may be a particular time ofday, a particular day of the week, or some other event.

At step 634, the forecasted states are provided to the push module 1300,which requests the forecasted state data related to the forecastedstates. At step 636, the response data comprising the forecasted statedata is prepared and transmitted to the mobile device 100.

At step 638, the prediction module 1200 determines if a successfulprediction notification has been received from the mobile device 100.The determination may be subject to a time-out period. For example, ifthe prediction module 1200 predicts forecasted states on a periodicbasis, the time-out period may be the prediction period, or a timeperiod less than the prediction period, e.g., one hour.

If a successful prediction notification is received, then at step 640the prediction data is adjusted by the prediction module 1200 for thereception of the successful prediction notification. Depending on theprediction algorithm used, adjusting the prediction data in step 640 mayresult in maintaining or increasing the likelihood of future predictionsfor the forecasted states predicted in step 632.

If a successful prediction notification is not received, however, thenat step 642 the prediction data is adjusted by the prediction module1200 for no reception of a successful prediction notification. Dependingon the prediction algorithm used, adjusting the prediction data in step642 may result in maintaining or decreasing the likelihood of futurepredictions for the forecasted states predicted in step 632.

In another embodiment, the successful prediction notification maycomprise data indicating whether the mobile device 100 accessed theresponse data provided at step 636. In this embodiment, the mobiledevice 100 is configured to determine whether the response data pushedfrom the push module 1300 has been accessed during an access timeperiod. If the response data has been accessed during the access timeperiod, then the successful prediction notification indicates that asuccessful prediction occurred. If the response data has not beenaccessed during the access time period, however, then the successfulprediction notification indicates that an unsuccessful predictionoccurred.

FIG. 7 is a diagram of another embodiment of a system for handlingmobile device information requests. In this embodiment, a predictionserver 200 is implemented in the wireless gateway 85 of FIG. 1, andillustratively comprises a Data Collection Unit (DCU) 210, a DataAdjustment Unit (DAU) 220, an Analysis and Prediction Unit (APU) 230,and a Data Preparation and Push Unit (DPPU) 240. The prediction server200 may be implemented at other locations, however, such as at theportal 10, or another server operable to communication with the wirelessdevice 100 over the network shown in FIG. 1.

The mobile device 100 comprises a prediction client 300, which mayinclude a State Reporting Agent (SRA) 310 and a Data Store (DS) 320 forpushed data. Also illustrated in FIG. 7 is a device application 330,which may be a mobile device browser, such as a WAP browser, or othermobile device communication program. The DS 320 may comprise a browsercache or mobile application-specific cache. The device application 330may be configured to check the DS 320 for cached information beforeissuing a data pull request to the prediction server 200, and the SRA310 may interact with a particular device application 330 to receivenotification of a user request for a specific URI. When notified, theSRA 310 utilizes the wireless connection to transmit URI data to theserver side DCU 210.

The device application 330 may also include the functionality of the SRA310 and the DS 320. For example, a WAP browser may report the mobiledevice state with each URI query, and the WAP browser cache may storeinformation for the WAP browser. Thus, the prediction server 200 andpushed response data may be integrated in a transparent manner to themobile device 100 user.

The DCU 210 may comprise a device state listener 212 and the statestorage component 214. When the mobile device 100 reports a new state,the state listener 212 receives the data, which typically comprises adevice ID and state URI, and redirects the data to the state storagecomponent 214. In alternate embodiments, the device state listener 212can be implemented as a socket server, stream connection listener, orservlet. The device state listener 212 may be embodied using software asa stand-alone process or as a thread within the DCU 210 or predictionserver 200. Other implementation schemes may also be used.

The state storage component 214 comprises a state data storage forstates received from the device state listener 212 and hierarchical datastorage of states structured according to mobile device users'historical activity patterns. States received from the device statelistener may be stored temporarily, while the hierarchical data storagemay be operable to store data persistently. The hierarchical datastorage may be implemented using a relational or object database, XMLdata store, or serialized files. Other file structures may also be used.

The DAU 220 is notified when a new state is provided to the data storageof the DCU 210. The DAU 220 receives the state URI and device ID fromthe state data storage and the corresponding historical data from theDCU 210 hierarchical data storage. The hierarchical data storage may beupdated according to a prediction algorithm, such as Markov weightedprobabilities, two-way sorting, n-gram sequence model, and the like. Inone embodiment of the DAU 220, two separate threads are utilized, afirst thread for new, state notification, and a second thread for stateprocessing.

The APU 230 is notified by the DAU 220 when the DAU 220 completes theupdate to the hierarchical data storage 214. The APU 230 then executesthe prediction algorithm on the data from the DCU 210 to predict thenext state or states of the mobile device 100. The next states mayrepresent the most likely user navigation steps following the currentrequested device 100 state.

The APU 230 may operate in three prediction modes: atomic mode, groupmode, and mixed mode. In a manner as previously described with respectto the embodiment of FIG. 2, the atomic mode operates on the historicalinformation of a particular mobile device 100 or a relatively smallgroup of homogeneous users, and makes predictions based on thisinformation. The group mode operates on a much greater data samplecollected on a large user population. The mixed mode operates on themobile device specific data first and, if there is not enoughinformation to make a strong prediction (e.g. either the preferencepattern is not recognizable or a sub-graph has not yet been visited bythe mobile device), the APU 230 switches to the group mode data to makea prediction.

The APU 230 prediction may comprise one or more forecasted states. TheDPPU 240 receives the forecasted states from the APU 230, and requestsand receives data associated with each forecasted state from theInternet 20 or local network 21. In one embodiment, the DPPU 240 mayincorporate content caching to optimize collection of the dataresponsive to the forecasted states.

After the response data related to the forecasted states are received,the DPPU 240 packs the forecasted states and associated response datainto a single buffer for transmission to the mobile device 100. The DPPU240 may also perform additional optimization steps, such as contenttranscoding, compressing, and the like. The DPPU 240 then provides theresponse data to a mobile gateway server to execute the push to themobile device 100.

The DS 320 at the mobile device 100 receives the set of response datatransmitted by the DPPU 240. In one embodiment, the DS 320 may berealized by a cache for a WAP browser operating on the mobile device100. In another embodiment, the DS 320 may be realized by a push cacheassociated with the device application 330. In the case of correctprediction, the next state selected at the mobile device 100 will besatisfied from the DS 320, and thus latency is minimized.

Operation of the embodiment FIG. 7 may be summarized according to thefollowing data operations as indicated by the referenced arrows. Upon anew state notification, the SRA 310 sends state information to DCU 210(1). The new state is recorded, and the DCU 210 notifies DAU 220 (2).The data storage is adjusted (3), if required, and the DAU 220 notifiesthe APU 230 (4). The APU 230 executes the prediction algorithm on theDCU 210 data (5), and the predicted states are provided to the DPPU 240(6). The DPPU 240, in turn, requests and receives the correspondingresponse data (7), and the response data and predicted states areprepared for transmission to the mobile device 100 (8).

These data operations need not occur according to the order depicted inFIG. 7. For example, the device application 330 may issue a traditionaldata pull request (9), which can be used as a trigger for initiating anyone or several of the operations described above.

In an alternative embodiment of FIG. 7, the APU 230 is further operableto execute the prediction algorithm on the data from the DCU 210 topredict the states of the mobile device 100 independent of a new statereported by the mobile device 100. For example, the APU 230 may predictthe states of the mobile device 100 on a periodic basis. For example, ifa user of the mobile device 100 typically access a news service and asports service during a certain time of day, e.g., between the hours of7:00 AM and 8:00 AM, the APU 230 may execute the prediction algorithm atthe beginning of this time period. In this embodiment, the DAU 220 mayalso be operable to receive a successful prediction notification fromthe mobile device 100 and update the state storage component in the DCU210.

FIG. 8 illustrates a weighted graph model of mobile device activity. Inthis graph model, each of the edges represent two directions, and eachof the vertices represents a mobile device state; such as a cHTML orxHTML pages, WAP deck, data screens, etc.

Moving along the edge represents a transition from a first state to anext state. Thus, if an edge exists between any two arbitrary vertices Aand B, then the edge represents both transition from vertex A to B andfrom B back to A, and has a pair of associated weights (W_(AB), W_(BA)),one weight per direction. For example, the edge connecting vertices V1and V2 has weights (W₁₂, W₂₁). In this regard, the edges denotebi-directional transitions between the information states.

During a training period, states requested by a mobile device or mobiledevices are observed. The weights for each vertex weight may representthe number or frequency of transitions along each direction of the edgeduring a training period, or may represent any other decision supportingmeasure based on subscriber historic activity.

The graph of FIG. 8 can be used to predict the most likely subset offuture transitions (edges) and response data (vertices) based on thecurrent information state of the mobile device and historicallyaccumulated user activity data. When the most likely set of futureinformation units is identified, it is pushed to the mobile device tominimize data access latency observed by a subscriber.

A variety of mathematical models and prediction algorithms may be usedto realize the graph of FIG. 8. In the embodiment of FIG. 7, forexample, a Markov chain model may be implemented. The weighteddirectional graph of FIG. 8 can be adapted as a Markov chain by ensuringthat edge weights are probabilities of transitions between statevertices. Thus, the graph may be normalized at each vertex in order foreach vertex to have the total weight of outgoing edges to be equal to aprobability of 1. The graph operates with the Markov chain statescorresponding to atomic units of information (e.g., cHTML or xHTMLdocuments, WAP decks, data screens, etc.) and edge transitions thatrepresent mobile user navigation from one vertex to another to predictforecasted states.

Ordinarily, a Markov chain model with n states S={s₁, s₂, . . . s_(n)}is fully described by a state vector Z_(t) and transition matrix T. Atany discrete moment t the state of the system can be stochasticallydefined using the formula:Z _(t) =TZ _(t-1) =T ^(t−1) Z ₀,

-   -   where Z₀ is an initial state of the chain.

A Markov chain model may also comprise a history-determined Markovchain. Unlike regular or state-determined chains, the future state ofthe history-determined Markov chain is described by not only the currentstate of the chain but rather by a finite sequence of preceding states.This class of Markov chains provides a more accurate model of dynamicsystems and also facilitates a self-learning system.

For a generic history-determined chain, the state vector can be definedas:Z _(t) =F(Z _(t-1) , Z _(t-2) , . . . , Z _(t-k)),

-   -   where F is a state transformation function and k is a history        depth. The set (Z_(t-1), Z_(t-2), . . . , Z_(t-k)) is a historic        states pattern, and may provide more accurate prediction results        than prediction results based on a single states pattern.

For the history-determined Markov chain, the wireless environment may bemodeled according to the follow propositions:

-   -   Cardinality of a Markov chain model for a generic multi-user        environment is virtually indefinite: lim_(t->∞)|S_(t)|=∞, and        tends to cover the whole sample space Ω;    -   Cardinality of a Markov chain modeling an activity of a single        user or a homogeneous group of users is much smaller and a        vector of states S_(t)={s₁, s₂, . . . s_(n)} at any given time t        represents only a subset of Ω; and    -   For a single user model, or a homogeneous group of users, the        following assumption (stochastic limitation of a state set        cardinality) applies:        -   if θ_(t) is an observed state of the model at a moment t            then:            ∀ρ->0 ∃n<∞: P{θ _(t) εS _(t)}>1−ρ and |S|_(t)<n        -   where P{A} is the probability of event A.

The graph of FIG. 8 is generated during a training mode. FIG. 9 shows anexemplary transition matrix T structure and adjustment process duringthe training phase. In each frame, P^(r) _(ls) represents a transitionprobability from state l to s as per matrix 430 state at the end offrame r. The state vector S and transition matrix T 430 may be adjustedby first defining collection frames 410. A collection frame is a timeinterval over which the model operates without changing S or T. At theend of each frame 410, the collected data is analyzed and S and T areadjusted for the next frame.

During the training phase 420, model space S is likely to grow, andduring the operational phase |S| will likely stay steady even though theindividual states might be added or removed reflecting user activitypattern changes. The frame size may change in transition from trainingto operational phase, as it is likely to grow until the system achievesstability.

A frequency analysis may be used to adjust S at the end of thecollection frame. For example, if a state θ was visited by the system atleast K times during the past frame, the state is added to vector S. Ifthe state θ was not visited by the system during the past M frames, thestate is removed from S. Removal of unused, or rarely used, model statesincreases performance efficiency by limiting the state size. Optimalvalues of K and M depend on application specifics and size of controlleduser group.

The transition matrix adjustment process occurs at the end of the firstcollection frame 410, at which time the frequency matrix F representsstate transitions: $F = {\begin{matrix}0 & f_{12} & \ldots & f_{1n} \\f_{21} & 0 & \ldots & f_{2n} \\\ldots & \ldots & \ldots & \ldots \\f_{n1} & f_{n2} & \ldots & 0\end{matrix}}$

-   -   where:    -   f_(ij) is a frequency of transitions from state i to state j;        and    -   n is a number of model states monitored during past collection        frame, and includes existing model states and new states visited        more than the threshold value K times during past collection        frame.

Weight coefficient α that represents a refresh rate for the transitionmatrix F may used for frame-adjusting the matrix T according to thefollowing relation:p _(ij) =αf _(ij)+(1−α)p _(ij), if i existed prior to the past framep_(ij)=f_(ij), otherwise

Note that if the transition matrix T is zero-extended for new statesprior to calculation, then the relation above is identical toT=αF+(1−α)T.

The weight coefficient α is adjusted during training and operationalphases so that α->0 as the model matures. Adjusting the weightcoefficient α will affect how rapidly the system converges during thetraining mode. Generally, a smaller incremental change in the weightcoefficient α will result in additional collection frames.

Unused or rarely used states are removed to complete the adjustmentprocess. If rows are removed for unused states, no further adjustment isrequired. If columns are removed for unused states, however, aprobability normalization is required. The probability normalization maybe expressed as:P _(ij) =P _(ij)/Σ_(j<m) P _(ij),

-   -   where m is a new number of states.

At a time t_(s), a saturation point is reached, and the systemtransitions to an operational mode. The saturation point may beexpressed as:Ω(ΔT)_(n) <X,

-   -   where        -   Ω is a metric defined on the matrix ΔP        -   (ΔT)_(n) is a matrix of probability adjustments over the            last collection frame n        -   X is a saturation point criterion.

The term X may be a predefined scalar number that represents aquantitative upper boundary for the frame-to-frame transition matrix Tadjustment, and Ω may be a norm defined on the matrix ΔT. The followingtwo matrix norms may be used for this purpose:

The Hilbert-Schmidt norm (sum of square differences):|ΔT| ₂={square root}Σ_(i,j)(Δt _(ij))² <X  (i)

The L1 maximum absolute column sum norm:|ΔT| ₁=max_(j)Σ_(i=1 . . . n) |Δt _(ij) |<X  (i)

Either of these norms provides a condition (i) for the selected matrixto satisfy over a number of consecutive frames, thereby triggering thesystem to change into an operational mode.

During the operational mode, the system predicts forecasted mobiledevice states based on the current mobile device state and historicallycollected data about states space S and transitional probabilitiesbetween states T. An exemplary prediction process may be based on thefollowing variables:

Prediction depth W: a maximum number of information units (Markov chainstates) that is time/price efficient to direct to the mobile deviceduring one push;

-   -   Transition path Z_(n): a set of ordered states Z_(n)={z₁, z₂,        z₃, . . . z_(n)}, n<W;    -   Probability metric P_(Zn): a composite probability measure        defined on the set Z_(n) to identify an optimal path out of all        possible paths;    -   Cost function C_(k): represents a cost of push data transmission        for k pages; and    -   Weight function F_(Zn)=P_(Zn)+βC_(n), where β is a cost weight        coefficient.

The prediction process predicts an optimal path Z_(n), based on thehistorical mobile device states. The predicted states z₁, . . . z_(n)and associated response data are pushed to the mobile device. Forexample, given x as a current state of the mobile device, the followingpredicted forecasted states may occur: $\begin{matrix}{i.} & ({consequent}) & {x->{z_{1}->{z_{2}->{z_{3}->{\ldots->z_{n}}}}}} \\{{ii}.} & ({parallel}) & {x->{z_{1}->z_{2}}} \\\quad & \quad & {x->{z_{3}->{\ldots->z_{k}}}} \\\quad & \quad & {x->{z_{2}->{z_{5}->{\ldots->z_{n}}}}}\end{matrix}$

Consequent states represent forecasted states that are predicted to besubsequently visited in response to the current state x. For example, ifthe next three consecutive states to be visited by the mobile device arepredicted to be URIs z₁, z₂ and z₃, then data for these states arepushed to the mobile device.

Parallel states represent all possible forecasted states that arepredicted to be visited in response to the current state x. For example,x is a vertex in a weighted directional graph, then the states z₁, z₂,and z₃ are connected to the state x by an edge weight.

For every new state of the mobile device, the prediction algorithm canbe configured for optimization, maximizing F_(Zn) over all possibleZ_(n) sets, n<W. A push occurs when the F_(Zn)>R₀, where R₀ is a pushvalidity threshold.

The cost function C_(k) may be used to ensure a cost effective push ofpredicted data to the mobile device. For example, ifC_(k)=0, W=1, thenF_(Zn)=P_(Zn)=P_(Z) ₁P _(Z) ₁ =Pxi (iεS, x is a current device state)

Then the resulting Z₁={i}: Pxi=max_(jεS)(Pxj), iεS.

Thus, a single state is forecasted and the response data is pushed tothe mobile device 100.

While pushing just a single state and its corresponding response data tothe mobile device may be practical for some information formats, e.g.WAP decks, it may be desirable to predict a forecast of multiple states.Thus,C_(k)=0, W>1F_(Zn)=P_(Zn)

A variable r₀ may be used to define a path selection probabilitythreshold. The variable r₀ may correspond to a threshold probability,and a state transition from i to j is selected if Pij>r₀. Accordingly,the magnitude of r₀ will be proportional to the cardinality of a set ofcandidate states Z^(c). From the set of candidate states Z^(c), the setof forecasted states Z_(n) can be selected.

The candidate set of predicted states Z^(c) is generated by firstselecting all states z₁ for which Pxz₁>r₀. States meeting this criteriaare then added to the set of predicted states Z^(c). For all of thestates in the set of predicted states Z^(c), a subsequent forecastedstate is predicted by selecting all states z₂ for which Pz₁z₂>r₀. Statesmeeting this criteria are then added to the set of predicted statesZ^(c), and a set of forecasted paths are stored (i.e. x->z₁->z₂).

The steps are repeated until one of three events occur: |Z^(c)|=W; orthe path length exceeds W (x->z₁->z₂ . . . ->z_(W)); or the selectionprocess cannot find any transition with Pz_(k)j>r₀ at the step k<W.

After the forecasted paths are generated, the candidate set of statesZ^(c) is evaluated to determine whether optimization is required. If|Z^(c)|≦W, then the predicted set of states Z_(n)=Z^(c). No optimizationis required, and the forecasted states and response data may be pushedto the mobile device.

If |Z^(c)|>W, however, then an optimization is required. Theoptimization may be expressed as:Z _(n) εZ ^(c) : P _(Zn)=max_(n≦W) P(Z ^(c))

The optimized forecasted states and response data may then be pushed tothe mobile device.

By adjusting the cost function C_(k) to a value greater than 0 so thatF_(Zn)=P_(Zn)+βC_(n), then the candidate set of states Z^(c) will beadjusted according to the value of the βC_(n) for each correspondingstate. Thus, by selecting r₀ and C_(k), the set of candidate statesZ^(c) may be selected subject to various system efficiencies andresources available.

An example of selecting a candidate set of states Z^(c) may beillustrated with reference to FIG. 8. Assuming the current mobile devicestate is v₁, then the next states are v₂ and v₅. If w₁₂>r₀, then v₁->v₂is stored as a forecasted path. Likewise, if w₁₅>r₀, then v₁->v₅ isstored as a forecasted path. If consequent forecasted states are to begenerated, then the forecasted path with the highest probability isstored. If parallel forecasted states are to be generated, however, thenboth v₁->v₂ and v₁->v₅ are stored as forecasted paths. The selectionprocess continues until one of the three termination events occurs.

In another embodiment, threshold r₀ is increased as the selectionprocess forecasts each subsequent prediction from the current devicestate. This approach results in a smaller set of forecasted states,accommodates both cost considerations C_(k) and validity threshold R₀,and simplifies the prediction process.

The probability measure P may be defined as a simple sum of transitionprobabilities along the paths in Z^(c). For a less specific P, thetransition paths should be kept intact while finding a maximizationsubset of candidate set Z^(c), i.e. if the state z_(m) is chosen, thenall the states in a path from x to z_(m) are to be chosen as well.

FIG. 10 is a flow diagram 700 illustrating another embodiment of thecandidate state selection process. At step 702, a requested state x isreceived from a mobile device. At step 704, a subset of states isselected from all states z₁ having a transition probability Pxz₁>r₀. Inthe embodiment of FIG. 10, states z₁ are all states having a transitionprobability from state x that is greater than 0. The subset of states isthen stored as the candidate set of states Z^(c).

Step 706 determines if additional states remain. Additional states mayremain, for example, if the selected subset of states from z₁ havetransition probabilities to other states z_(n). If additional states areavailable, then another subset of states is selected, as shown in step708, and the state paths are stored in the candidate set of statesZ^(c). Step 710 then determines if additional states remain. If so,state selections are incremented, as shown in step 712, and step 708 isrepeated.

Once no additional states remain, as determined by either step 706 or710, then step 714 determines if an optimization of the candidate setZ^(c) is required. If optimization is required, then step 716 optimizesthe candidate set Z^(c) in a manner as previously described. Afteroptimization, or if no optimization is required, then the forecastedstates Z^(n) are set to the candidate set Z^(c), as shown in step 718.

FIG. 11 is a schematic diagram of components that could make up awireless device that could be used as a mobile device with theinvention.

Turning now to FIG. 11, there is a block diagram of a wireless device900 in which portions of the instant invention may be implemented. Thewireless device 900 is preferably a two-way communication device havingat least voice and data communication capabilities. The devicepreferably has the capability to communicate with other computer systemson the Internet. Depending on the functionality provided by the device,the device may be referred to as a data messaging device, a two-waypager, a cellular telephone with data messaging capabilities, a wirelessInternet appliance or a data communication device (with or withouttelephony capabilities).

Where the device 900 is enabled for two-way communications, the devicewill incorporate a communication subsystem 911, including a receiver912, a transmitter 914, and associated components such as one or more,preferably embedded or internal, antenna elements 916 and 918, localoscillators (LOs) 913, and a processing module such as a digital signalprocessor (DSP) 920. The particular design of the communicationsubsystem 911 will be dependent upon the communication network in whichthe device is intended to operate. For example, a device 900 destinedfor a North American market may include a communication subsystem 911designed to operate within the Mobitex mobile communication system orDataTAC mobile communication system, whereas a device 900 intended foruse in Europe may incorporate a General Packet Radio Service (GPRS)communication subsystem 911.

Network access requirements will also vary depending upon the type ofnetwork 919, such as Wireless Network 105 of FIG. 1. For example, in theMobitex and DataTAC networks, mobile devices such as 900 are registeredon the network using a unique personal identification number or PINassociated with each device. In GPRS networks, however, network accessis associated with a subscriber or user of a device 900. A GPRS device,therefore, requires a subscriber identity module (not shown), commonlyreferred to as a SIM card, in order to operate on a GPRS network.Without a SIM card, a GPRS device will not be fully functional. Local ornon-network communication functions (if any) may be operable, but thedevice 900 will be unable to carry out any functions involvingcommunications over network 919. When required network registration oractivation procedures have been completed, a device 900 may send andreceive communication signals over the network 919. Signals received bythe antenna 916 through a communication network 919 are input to thereceiver 912, which may perform such common receiver functions as signalamplification, frequency down conversion, filtering, channel selectionand the like, and in the example system shown in FIG. 11, analog todigital conversion. Analog to digital conversion of a received signalallows more complex communication functions, such as demodulation anddecoding, to be performed in the DSP 920. In a similar manner, signalsto be transmitted are processed, including modulation and encoding, forexample, by the DSP 920 and input to the transmitter 914 for digital toanalog conversion, frequency up conversion, filtering, amplification andtransmission over the communication network 919 via the antenna 918.

The DSP 920 not only processes communication signals, but also providesfor receiver and transmitter control. For example, the gains applied tocommunication signals in the receiver 912 and transmitter 914 may beadaptively controlled through automatic gain control algorithmsimplemented in the DSP 920.

The device 900 preferably includes a microprocessor 938, which controlsthe overall operation of the device. Communication functions; includingat least data and voice communications, are performed through thecommunication subsystem 911. The microprocessor 938 also interacts withfurther device subsystems, such as the display 922, flash memory 924,random access memory (RAM) 926, auxiliary input/output (I/O) subsystems928, serial port 930, keyboard 932, speaker 934, microphone 936, ashort-range communications subsystem 940 and any other device subsystemsgenerally designated as 942.

Some of the subsystems shown in FIG. 11 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 932 and display922, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork and device-resident functions such as a calculator or task list.

Operating system software used by the microprocessor 938 is preferablystored in a persistent store such as flash memory 924, which may insteadbe a read only memory (ROM) or similar storage element (not shown). Theoperating system, specific device applications, or parts thereof, may betemporarily loaded into a volatile store such as RAM 926. It iscontemplated that received communication signals may also be stored toRAM 926. Flash memory 924 preferably includes data communication module924B, and when device 900 is enabled for voice communication, a voicecommunication module 924A. Also included in flash memory 924 are othersoftware modules 924N, which are also shown as prediction client 300 ofFIG. 7.

The microprocessor 938, in addition to its operating system functions,preferably enables execution of software applications on the device. Apredetermined set of applications that control basic device operations,including at least data and voice communication applications, forexample, will normally be installed on the device 900 duringmanufacture. A preferred application that may be loaded onto the devicemay be a personal information manager (PIM) application having theability to organize and manage data items relating to the device user,such as, but not limited to, e-mail, calendar events, voice mails,appointments, and task items. Naturally, one or more memory stores wouldbe available on the device to facilitate storage of PIM data items onthe device. Such PIM application would preferably have the ability tosend and receive data items via the wireless network. In a preferredembodiment, the PIM data items are seamlessly integrated, synchronizedand updated, via the wireless network, with the device user'scorresponding data items stored or associated with a host computersystem. Also preferred is a browser application, such as deviceapplication 330 of FIG. 7. Further applications may also be loaded ontothe device 900 through the network 919, an auxiliary I/O subsystem 928,serial port 930, short-range communications subsystem 940 or any othersuitable subsystem 942, and installed by a user in the RAM 926 orpreferably a non-volatile store (not shown) for execution by themicroprocessor 938. Such flexibility in application installationincreases the functionality of the device and may provide enhancedon-device functions, communication-related functions, or both. Forexample, secure communication applications may enable electroniccommerce functions and other such financial transactions to be performedusing the device 900.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem911 and input to the microprocessor 938, which will preferably furtherprocess the received signal for output to the display 922, oralternatively, to an auxiliary I/O device 928. A user of device 900 mayalso compose data items, such as e-mail messages, for example, using thekeyboard 932, which is preferably a complete alphanumeric keyboard ortelephone-type keypad, in conjunction with the display 922 and possiblyan auxiliary I/O device 928. Such composed items may then be transmittedover a communication network through the communication subsystem 911.

For voice communications, overall operation of the device 900 issubstantially similar, except that received signals would preferably beoutput to a speaker 934 and signals for transmission would be generatedby a microphone 936. Alternative voice or audio I/O subsystems, such asa voice message recording subsystem, may also be implemented on thedevice 900. Although voice or audio signal output is preferablyaccomplished primarily through the speaker 934, the display 922 may alsobe used to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information, forexample.

The serial port 930 would normally be implemented in a personal digitalassistant (PDA)-type communication device for which synchronization witha user's desktop computer (not shown) may be desirable, but is anoptional device component. Such a port 930 would enable a user to setpreferences through an external device or software application and wouldextend the capabilities of the device by providing for information orsoftware downloads to the device 900 other than through a wirelesscommunication network. The alternate download path may, for example, beused to load an encryption key onto the device through a direct and thusreliable and trusted connection to thereby enable secure devicecommunication.

A short-range communications subsystem 940 is a further optionalcomponent which may provide for communication between the device 900 anddifferent systems or devices, which need not necessarily be similardevices. For example, the subsystem 940 may include an infrared deviceand associated circuits and components or a Bluetooth™ communicationmodule to provide for communication with similarly-enabled systems anddevices.

This written description uses illustrative embodiments to disclose theinvention, including the best mode, and also to enable a person ofordinary skill in the art to make and use the invention. Otherembodiments are within the scope of the claims if they have elementsthat do not differ from the literal language of the claims or haveequivalent elements.

1. A system for handling data requests from mobile devices, the system comprising: a memory operable to store data requests received from at least one mobile device; a state prediction module operable to access the memory and predict a first forecasted data request for a mobile device based on the stored data requests; and a push module operable to receive the first forecasted data request from the state prediction module and in response request and receive first response data related to the first forecasted data request and prepare the first response data for transmission to the mobile device over a wireless network.
 2. The system of claim 1, wherein the first forecasted data request is predicted in response to receiving a data request from the mobile device.
 3. The system of claim 2, wherein the state prediction module is further operable to generate prediction data based on the stored date requests, and to update the prediction data based on the reception of a prediction notification received from the mobile device in response to the first response data.
 4. The system of claim 1, wherein the state prediction module is further operable to predict the first forecasted data request independent of a data request received from the mobile device.
 5. The system of claim 4, wherein: the state prediction module is further operable to receive a data request from the mobile device and in response access the memory and predict a second forecasted data request based on the received data request and the stored data requests; and the push module is further operable to receive the received data request and the second forecasted data request from the state prediction module and in response request and receive second response data related to the received data request and the second forecasted data request and prepare the second response data for transmission to the mobile device over a wireless network.
 6. The system of claim 4, wherein the state prediction module is further operable to predict the first forecasted data request on a periodic basis.
 7. The system of claim 5, wherein the state prediction module is further operable to select prediction modes according to the identified subset of stored data.
 8. The system of claim 7, wherein the prediction modes comprise: an atomic mode that operates on stored data requests specific to the identity of the mobile device; and a group mode that operates on stored data requests specific to a plurality of mobile devices.
 9. The system of claim 5, wherein the state prediction module comprises a Markov chain module operable to predict the first and second forecasted data requests.
 10. The system of claim 5, wherein the second forecasted data request comprises a set of consecutive data requests and consecutive response data referenced from the received data request.
 11. A computer implemented method for handling date requests from mobile devices, the method comprising: receiving and storing data requests received from the mobile devices; comparing a received data request from a mobile device to prediction data to predict forecasted data requests based on the comparison; requesting and receiving response data related to the received data request and the forecasted data requests; and preparing the response data for transmission to the mobile device over wireless network.
 12. The method of claim 11, further comprising the steps of: identifying the mobile device from the data request; identifying a subset of prediction data based on the identity of the mobile device; and comparing the subset of stored data requests to the received data request to predict the forecasted data requests.
 13. The method of claim 12, further comprising the steps of: assigning a probability value to the forecasted data requests; comparing the probability value to a threshold; if the probability value does not exceed the threshold, then: expanding the subset of prediction data to include data requests from other mobile devices; and predicting further forecasted data requests based on the expanded prediction data.
 14. The method of claim 11, wherein the step at comparing a received data request from a mobile device to prediction data to predict forecasted data requests based on the comparison comprises the steps of: selecting a set of states having a transition probability from a current mobile device state greater than a selection probability threshold; incrementing the set of states until the set of states transition probability from the current mobile device state is less than the selection probability threshold.
 15. The method of claim 14, wherein the step of comparing a received data request from a mobile device to prediction data to predict forecasted data requests based on the comparison further comprises the steps of: determining a cardinality of the set of states; comparing the cardinality of the set of states to a maximum depth; if the cardinality of the set of states exceeds the maximum depth, then adjusting the set of states.
 16. The method of claim 15, wherein the step of adjusting the set of states comprises: limiting the set of states to the maximum depth; and selecting a subset of the set of states such that the transition probability from the current mobile device state is maximized.
 17. The method of claim 14, further comprising the step of incrementing the selection probability threshold after each increment to the set of states.
 18. The method of claim 11, further comprising the step of predicting an independent forecasted data request for a mobile device independent of a data request received from the mobile device.
 19. The system of claim 18, further comprising the step of receiving a successful prediction notification from the mobile device and updating the prediction data based on the successful prediction notification.
 20. The system of claim 18, wherein the step of predicting an independent forecasted data request is performed on a periodic basis. 